Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
A jam submission

Pickle EngineView game page

Submitted by Stuart Heath (@pkplonker) — 7 days, 5 hours before the deadline
Add to collection

Play game

Pickle Engine's itch.io page

Results

CriteriaRankScore*Raw Score
UI/UX Consideration#33.3614.000
Code + Technical#5n/an/a
Features & Additions#63.2213.833
Overall#92.3802.833
Creativity#132.1002.500
Gameplay Implementation#140.8401.000

Ranked from 6 ratings. Score is adjusted from raw score by the median number of ratings per game in the jam.

Judge feedback

Judge feedback is anonymous and shown in a random order.

  • This project did not really follow the brief so it does not make it easy to assess. On the other hand though, I think it provides a good portfolio piece for CoreTech positions and it's a good step on improving your coding skills and expanding your knowledge. If you build a game one day -even a small one- using your own engine, it will definitely be a very impressive entry to make your profile stand out! - Gameplay Unfortunately, your submission performs poorly here as it is not focusing on building a game and therefore, does not have any gameplay elements that we can assess. Despite that, I can acknowledge that an implementation of some more advanced features is there (e.g. undo system, data serialization) and there is a reference to a few things that modern game engines and their respective editors support and provide to the user (GUID, file and resource handling etc.). These can definitely be improved, refactored and optimized but is good that they are there. - UI/UX Using the editor was pretty straightforward overall. Good choice for using IMGUI for that! I did encounter a few bugs (a crash if you try to set the camera FOV close to zero, the viewport scales/stretches if you resize its window) but overall I think it was a good approach for a prototype. - Features As mentioned above, there are some advanced features here which is great to see and the engine offers an ECS pattern which is quite common in the industry. It will be nice to be able to have a small demo that was developed using your engine and editor at some point. Another opportunity to showcase your work would be to have a small tutorial when starting the editor for the very first time (yes, even Editors need some form of tutorialization!). - Creativity, Design & Originality Although there idea is not that original, I think there are couple of good points here. The provided documentation outlined what one would expect. I think the idea of using source control is proficient and your GitHub page looks good. Kudos for choosing Trello as a roadmap and planning tool - this was an excellent idea and it's a great resource to pair with your project! Jason Tzaidas (Rocksteady)
  • Clean-ish release ZIPs - debatable whether the PDBs are needed Technical Assessment will show how much 3rd party tech has been involved, IMGUI clearly has. Has effectively lost the original demo elements, contrary to what was asked Rather ambitious scope, but seems largely successful Decent documentation
  • This is a really interesting submission. It unfortunately doesn't meet the spec criteria of "Create a finished, playable game prototype using the base project provided" but this aside, what you have created is impressive and clearly had a lot of care, attention, and time put into it. This does however make it difficult to grade against the assessment criteria, so I'll give a brief overview of my thoughts how the project faired against those, then more detailed feedback which will focus on the specifics of what you've achieved, instead of it's relation to the original assignment. ~ Brief --- Criteria --- -- Gameplay As expected, this is where the submission didn't really hit many of the objectives. There isn't really a game there, or an attempt at one as the GameBase project contains only a windows entry point. What could have been nice here is a very simple sample game implementation instead to serve as the GameBase. -- UI/UX Addition of an editor was a good step towards this objective. The editor is responsive and implements many UI features. The original spec is more targeted towards UX as it pertains to a game, but general tooling UX is also something worthy of consideration which you did. -- Features The addition of the editor itself is a signfiicant feature addition. Not to mention your addition of: - 3D model support - Scene serialization - Render stats tracking Sample game projects here could have helped score some easy wins against the assessment criteria, though it's understandable that the 4 features mentioned above alone will have eaten all of the reasonable development time. -- Creativity, Design, and Originality Along with "Gameplay", I think this is also an area where this kind of submission will have difficulties. Editors are fairly standard tools which can hamper your ability to express aspects of oiriginal design. One way I think you could have achieved this better is with better documentation of the development process as well as the specifics of the features you created. ~ Extended feedback --- Write-Up --- Project Management Your usage of Git is professional and in line with what you will see in real-world projects. In your write-up, you identify that you sometimes get lazy with the commit messages; it's good to be aware of that and not to fall into bad habits. However, after looking through the git commit history, there are only a few instances of these. One area to improve is to consider utilizing the project management tools within GitHub itself. The Projects section provides Trello-like Kanban boards, but with the added benefit that linked issues can be created directly via the board. This, in turn, lets you reference the issue (where you might have gone into more detail about the task) through your commit messages ("Specular lighting (#93)"). If this is due to the original brief suggesting you use BitBucket, then disregard this comment. Reflection You explain well the difficulties you encountered with using C++ when compared to languages such as C#. Memento is an interesting idea, but as you highlight, this may not work well for a language like C++. I'll make a suggestion in the implementation section. You identify a clear direction you can take as your next step: Learning a (non-MSBuild) build system such as CMake or Premake. It's a solid next step as reliance on manually maintained .vcxproj files tends to be a beginner trap. --- Implementation --- Extensions to Engine The extensions to the engine show a clear understanding of the purpose of the engine layer as well as experience in other engines. Your familiarity with Unity here is clear from the GameObject-Component system you've added. The C# experience shines through as well as the Logging system you've added, very Serilog-ish with its attachable Sinks. Neither of these is a negative. It's a solid way to architect an engine. It is also nice to see a GUID system being used to be able to uniquely reference your assets. However, one criticism here is that treating GUIDs as strings after creation is wasteful. Either using GUID directly, or if wanting to not rely on Windows for something so global, creating a custom GUID struct consisting of a pair of uint64_ts would have been much more efficient. Extending what is effectively a 2D base with only a billboard to have full 3D support and fbx support? Great. Much further development of the engine than I think anyone expected. Editor The addition of an IMGUI-based editor is a great idea. The code around it is decently structured. Be careful with some of usages of static and globals though, these can make it a little tricky to find where an object is stored and who is responsible for it's management. There is also a number of areas you may benefit from better usage of smart pointers in some areas, especially unique_ptr. Read up on modern usage of unique_ptr with respect to "move semantics" and "return value optimization (RVO)". LearnCpp.com has some excellent sections on this in Chapter 22. General Comments shared_ptr In your write-up, you highlighted the difficulty of moving from C# where references are tracked for you, to C++ and its much more fragile and less safe memory model. Be careful not to over-compensate with the usage of shared_ptr here. Unlike in C# where the reference tracking uses Mark and Prune for its garbage collection so flaws like circular islands preventing collection won't happen, reference-counting C++ smart pointers are very vulnerable to situations like this. Instead, try to think of your usage of smart pointers as a representation of ownership. Where "unique_ptr" represents strong ownership, "shared_ptr" should represent actual shared ownership. In your implementation, are the components truly shared ownership? I'd argue no. They are owned by the GameObject to which they're attached. Would a more "handle" style of referencing work here instead? Something to investigate! For GameObjects, the GUID would have been an appropriate handle. Aside from general cleanliness, a big benefit from using handles in this way is that serializing becomes simple as the handle itself can just be saved. RAII "// need to look at RAII. No finally block in C++ :/" RAII is a very simple concept with an overly complicated name. IDisposable in C# is that language's attempt to achieve the same goal, only in C++ it's automatic via scope-based destructor calls instead of explicit "using" keywords. It would've been interesting to see what you were thinking of doing here, but it's a positive that you were aware of how the concept would likely solve an issue you were having without knowing the specifics of how to use it (yet). Undo/Redo A robust solution to this would have likely taken longer to robustly implement than the project duration. For future reading, one option you could consider here is creating a standardized "Document Object Model" where you create a standard, generic representation for all your editor side data. The project is C#, but the Sony Authoring Tools Framework is a good implementation of this idea: [link removed]. A benefit of this approach is serialization, undo, and all forms of change tracking become centralized and trackable via handles relative to the root of your DOM system. This type of system will also make sections of the editor easier as it will remove the need for wrapping editor actions in a traceable "UndoableX" wrapper method, as change tracking instead could have been handled via routing change notifications via bubbling up to the root of the DOM system. -- Conclusion -- Great work! It would make a brilliant portfolio piece when applying to studios, especially if you continue development of it. Hope to see you submit something for Search for a Star in your final year! Carl Jones [Sumo]
  • The engine is a very serious work, but I'm not sure to be honest how to rate it in terms of this particular competition, it's rules and rating criteria.

Challenge Tier

Rising Star

Leave a comment

Log in with itch.io to leave a comment.

Comments

No one has posted a comment yet